apps/web/tests/workflows/utils/verify-campaign-sent.ts (1)

27-32: Assertions are tautological given the query's where clause.

The findFirst query already filters by campaignId, type: "Campaign", and partnerId, so asserting those same fields on the result will always pass. The only meaningful check is that the record exists (which the if (emailSent) guard already covers). Consider removing lines 28–31 to reduce noise, or keep them intentionally as documentation of the expected shape.

Simplified return

     if (emailSent) {
-      expect(emailSent).toBeDefined();
-      expect(emailSent.type).toBe("Campaign");
-      expect(emailSent.campaignId).toBe(campaignId);
-      expect(emailSent.partnerId).toBe(partnerId);
       return emailSent;
     }

apps/web/tests/workflows/utils/verify-bounty-submission.ts (1)

22-22: Consider typing lastSubmission instead of any.

Using the Prisma-generated type (e.g., BountySubmission | null) would give you compile-time safety on the error-message field access (line 59: lastSubmission.status, lastSubmission.performanceCount).

Type-safe alternative

+import { BountySubmission } from "@dub/prisma/client";
 ...
-  let lastSubmission: any = null;
+  let lastSubmission: BountySubmission | null = null;

apps/web/tests/workflows/award-bounty-workflow.test.ts (2)

10-42: trackLeads is duplicated verbatim in move-group-workflow.test.ts.

This helper appears identically in both award-bounty-workflow.test.ts (here) and move-group-workflow.test.ts (lines 12–44). Extract it to a shared utility under tests/workflows/utils/ to keep both files DRY and ensure future changes (e.g., adding delays, changing the tracking payload) are applied consistently.

Extract to shared utility

Create apps/web/tests/workflows/utils/track-leads.ts:

import { expect } from "vitest";
import { E2E_TRACK_CLICK_HEADERS } from "../../utils/resource";

export async function trackLeads(
  http: any,
  partnerLink: { domain: string; key: string },
  count: number,
) {
  for (let i = 0; i < count; i++) {
    const { status: clickStatus, data: clickData } = await http.post({
      path: "/track/click",
      headers: E2E_TRACK_CLICK_HEADERS,
      body: {
        domain: partnerLink.domain,
        key: partnerLink.key,
      },
    });

    expect(clickStatus).toEqual(200);
    expect(clickData.clickId).toBeDefined();

    const { status: leadStatus } = await http.post({
      path: "/track/lead",
      body: {
        clickId: clickData.clickId,
        eventName: `Signup-${i}-${Date.now()}`,
        customerExternalId: `e2e-customer-${i}-${Date.now()}`,
        customerEmail: `customer${i}@example.com`,
      },
    });

    expect(leadStatus).toEqual(200);

    await new Promise((resolve) => setTimeout(resolve, 200));
  }
}

---

104-160: Hardcoded 10-second sleep is fragile.

Line 147 uses a fixed 10-second wait to give the workflow time to not execute. If the system is slow, the workflow might still be processing, causing a false pass (draft found before workflow completes). If it's fast, 10 seconds is wasted CI time. Consider polling briefly (e.g., 2–3 iterations) and asserting draft status holds, or document why 10 seconds is a safe upper bound.

apps/web/tests/workflows/move-group-workflow.test.ts (2)

170-176: sourceGroup selection via existingGroups[0] is order-dependent and fragile.

Multiple tests (lines 176, 262, 336, 420) grab existingGroups[0] as the source group. The order of results from GET /groups may not be deterministic, and if another test creates a group before this one runs (even with sequential execution), the first element could change. Consider filtering by the known default group ID or slug instead:

Pin to the known default group

-    const sourceGroup = existingGroups[0];
+    const sourceGroup = existingGroups.find(g => g.slug === "default");
+    expect(sourceGroup).toBeDefined();

---

492-540: AND-operator test validates configuration but not execution.

This test verifies the workflow's triggerConditions are stored correctly with two rules, but doesn't test that both conditions must be satisfied for the move to occur (i.e., no execution test with one condition met and one not). Consider adding a follow-up test that exercises the AND semantics end-to-end.

apps/web/tests/workflows/utils/verify-bounty-submission.ts (1)

34-52: Redundant assertions inside the already-matched condition block.

Lines 40–46 re-assert conditions that were already verified by the if guard on lines 34–39. These expect calls will always pass at this point. They add noise without catching new failures. Consider removing them and keeping only the completedAt assertion (line 48–50), which checks something not in the guard.

♻️ Suggested simplification

     if (
       submission &&
       submission.status === expectedStatus &&
       (minPerformanceCount === undefined ||
         (submission.performanceCount ?? 0) >= minPerformanceCount)
     ) {
-      expect(submission.status).toBe(expectedStatus);
-
-      if (minPerformanceCount !== undefined) {
-        expect(submission.performanceCount).toBeGreaterThanOrEqual(
-          minPerformanceCount,
-        );
-      }
-
       if (expectedStatus === "submitted") {
         expect(submission.completedAt).not.toBeNull();
       }

       return submission;
     }

apps/web/tests/workflows/move-group-workflow.test.ts (1)

12-13: Consider typing the http parameter.

http: any loses type safety. If the IntegrationHarness exposes a type for its HTTP client, using it here would catch mistakes at compile time.